Most modern organizations use machinery, buildings, computers, vehicles and various other types of equipment to fulfill their tasks on a day-to-day basis. Such assets consume resources, suffer degradation and incur maintenance and replacement costs.
Deficient asset management, especially in asset-intensive industries, such as discrete and process manufacturing, transportation, and utilities, leads to overspending, loss of productivity and waste. The main drivers to adopt an automated enterprise asset management solution are improving overall profitability, asset utilization, asset performance, equipment upkeep and uptime, budgeting/planning and increasing inventory turns.
Many organizations recognize untapped value inherent within their corporate assets but are unable to access and deliver this value because of reliance on manual, data-starved processes. Asset-heavy companies have facilities geographically dispersed, production equipment with various interfaces and protocols, vehicle fleet and IT infrastructure using legacy, paper-based processes for the up keeping, organizing and maintaining their critical assets.
Asset management decisions can be only as good as the data on which they are based. Inaccurate and untimely data regarding an asset condition, utilization, and location will lead to sub-optimal decision-making. Critical asset data points such as historical and budgeted maintenance costs, warranty and license compliance, and facility and fleet utilization are often unstructured and collected randomly. Indeed, most asset-heavy organizations are currently using a paper-based system to manage and track their assets.
In order to properly manage assets, their status has to be monitored through time. Asset management decisions should be made in light of precise measurements and benchmarks. In today's connected and information-centric world, asset usage can indeed be thoroughly measured: assets, whether mobile or stationary, host computing devices that provides precious data about their day-to-day utilization and performance. This data is the raw material of the asset management process.
Dispersed assets of various types should not imply a fragmented asset management strategy. On the contrary, diverse assets are often interdependent and need to be managed as a whole so that their bottom-line impact on an organization can be fully understood.
This holistic approach is impeded by the very nature of assets and the environment in which they are being used: most of the time various assets are networked through different protocols, are remote and not easily accessible. Oftentimes, they disconnect from the network and become unavailable for an undefined period of time, for example in the case of mobile assets. These mobile assets are also subject to physical constraints over which, very often, minimal control can be exerted.
In addition, the dissemination of assets has generally meant that data about these assets is also scattered, buried in isolated and independent data silos: databases of all types, spreadsheets, paper-based reports. The outcome is that most organizations have a partial, fragmented and incomplete view of the assets they own. Isolated asset management will result in sub-optimized and erroneous analysis and can severely limit an organization's ability to make sound decisions regarding asset maintenance, labor planning, parts procurement, inventory control, not to mention more strategic decisions, such as productivity improvements or asset reuse, refurbishment, and retirement.
A large portion of asset management consists of deriving structured and actionable information from unstructured asset data so that decision makers at every level of an organization, from the shop floor to the top floor, or from sensor-to-boardroom (S2B), can make decisions ranging in complexity from labor assignment to asset depreciation and reinvestment planning. These decision makers need access to this asset data in unique formats and at specific times. Relying on static spreadsheets and file cabinets brimming with paper files, asset managers cannot provide their organizations with this kind of data aggregation, normalization, and dissemination.
Thus, access to valuable actionable information can only be obtained by breaking barriers between data silos within the organization. This information integration process creates new, synthetic information on the basis of which asset management decisions are ultimately taken.
The information integration process is made difficult by numerous factors that the asset management process only accentuates: First, the large amount of information: recent studies indicate that business-relevant information is growing at around 50 percent compound annual growth rate with about one to two exabytes (1018) of information being generated each year.
Second, the heterogeneity of data has resulted in the fact that records no longer sit in well-defined relational database tables (typically referred to as structured data). Increasingly, organizations have to deal with unstructured content such as text (in e-mails, Web pages, etc.), audio (call center logs), and video.
Third, the federation and distribution of data is no longer confined to sets of databases (such as in a data warehouse), but is distributed across multiple computers, potentially spanning different organizations. In addition, federation (who owns and controls the data and has access to it) is a new problem that distributed database technology has typically not addressed. In federation scenarios, one typically cannot assume full SQL (Structured Query Language) or other standard-based query languages.
Fourth, the data needs to be manipulated, aggregated, transformed, and analyzed in increasingly complex ways to produce business intelligence. A large fraction of the growth in relational databases in the early to mid-1990s was fueled by business intelligence in tasks ranging from decision support through complex SQL queries, to on-line analytical processing (OLAP), and all the way to data mining.
Fifth, the exponential increase in the amount of produced data and the disparity among data sources hinders the ability for decision makers to sift through information and act upon it. This suggests that some actions should be automated. Eventually, automated business rules can trigger business processes (which can also be automated, wholly or in part).
Conclusions drawn from the analysis of past asset management installments together with recent technological developments enable a paradigm shift that will result in comprehensive and optimal solutions that address the whole spectrum of problems pertaining to asset usage, from physical resources to strategic decisions and actions.
Indeed, with the advent of highly integrated computing power into low cost microprocessor and memory, wireless communication, constant improvements in computer architecture, the progress of miniaturization, and the development of high-level, dynamic and standard-based programming languages for constrained environments, embedded devices are becoming an integral part of the computing landscape. Indeed, for many years, devices have been limited to low-level sensing and relaying of data, performing little work onto the devices themselves. This has been the trademark of (Supervisory Control and Data Acquisition) SCADA applications. Furthermore, the very nature of the technology used to implement SCADA has induced tight coupling between the applications and the hardware on which they are deployed, for applications have been typically designed with statically compiled languages that have strong ties with low-level, device-specific functions. The combination of lower grade execution environments and strong coupling with hardware has resulted in SCADA applications being functionally minimalist, and difficult to maintain and quasi impossible to evolve.
In the future, devices will be able to process data and store it locally for undefined periods of time; high-level and dynamic programming languages will act as an abstraction layer between applications and hardware—making applications device-independent. Consequently, applications will grow in complexity; new functionalities will be added in the form of software updates—sparing the replacement of hardware, or direct access to said hardware. In such a context, the ability to centrally deploy and maintain multiple applications on multiple devices dispersed on a large scale will become a necessity.
The proliferation of devices will in great part be made possible by improvements in networking, best embodied by the advent of the internet and burgeoning wireless technology. Wireless networks have characteristics that will impact how distributed applications embedded within devices will be interconnected. Indeed, wireless networks are characterized by intermittent connectivity (this is especially true in the case of mobile assets, which can be in the surroundings of a wireless network at one moment, and disconnected at another) and by changing topology (devices in a wireless network can appear and disappear, especially in the case of mobile devices). The bandwidth of wireless networks can also vary greatly not only because of the number of peers on the network and network usage (which also affects wired networks), but also because of physical constraints (weather, geographical obstacles . . . ) over which no human control can be exerted. In addition, wireless networks often have limited range (from a couple to several hundred feet).
Various types of networks and networking conditions may impede application portability and behavior if no precautions are taken at design time. Furthermore, in many ways, improvements in network connectivity, both from hardware and software standpoints will have significant consequences on application design and distribution. Supervisory Control and Data Acquisition (SCADA) applications have been built around the client-server model: a centralized facility stores raw data acquired through communication links with devices. Processing of the said data is thus performed centrally. If the number of devices becomes large and the amount of data acquired from these devices also reaches a considerable level (which is often the case), the centralized facility quickly becomes overwhelmed. Adding more processing power to the centralized facility can create more problems, such additional costs and management issues. In addition, strong dependency on a centralized facility makes embedded applications highly vulnerable to networking failures: should the connection between devices and the centralized facility fail, precious data might eventually be lost.
Combined with improvements at devices themselves (processing power, storage capacity, high-level and OS-agnostic languages), new networking possibilities enable a shift from the client-server model (adopted by SCADA applications) to the peer-to-peer one. This shift yields highly distributed and pervasive architectures, with devices acting as semi-autonomous entities, connecting intermittently to potentially many networks in order to provide accumulated data (storing and processing it in the meantime), to offer software services to other devices and to act as relays between devices—for example in cases where range is limited. In addition, device autonomy is further improved through asynchronous communications, where receivers of messages are spared from having to respond immediately to senders. The asynchronous model decouples senders and receivers, allowing for better reliability in case of network failures (responses can be sent when the network becomes available), and scalability (a device can store a request locally, until it has sufficient resources to process it). Yet, sometimes, it is preferable and even necessary that synchronous communications be used (for example in the case of data streaming).
Furthermore, use of static addressing as commonly found in traditional SCADA systems forbids the creation of ad-hoc networks (where participants are not necessarily known in advance) and couples communicating parties with one another. Nowadays, distributed computing frameworks provide mechanisms to avoid static addressing; these mechanisms often rely on multicast, naming services or so-called “rendez-vous”, and are often used jointly. The present invention allows network participants to appear in the network and communicate with other nodes dynamically, without having to know each other in advance.
The emergence of embedded applications and the proliferation of devices bring up possibilities, but also entail a new problem: that of remote management. Application management encompasses various tasks pertaining to the application life cycle: once an application has been implemented, it has to be deployed. After deployment, it should be monitored (to ensure proper operation). At times, some actions must be triggered through human intervention (in response to specific conditions)—this suggests that applications should provide a minimal administration interface. Eventually, a new version of deployed applications will be made available: older versions should thereafter be updated. On a personal desktop computer, the application updates appear trivial. But when such tasks have to be performed on multiple remote devices, they become impossible to realize without the proper infrastructure.